Signed URL 기반 접근 제어
단순 파일 제공 구조가 아니라,
Firebase Storage에 대한 직접 접근을 제한하고,
제한된 시간 동안만 접근 가능한 다운로드 구조를 구성하였습니다.
개요
기존 개발자가 작성한 코드를 수정하며, 개발사에서 가장 우려하던 부분은 과연 현재 구조가 서비스 규모 확장 이후에도 안전한가였습니다.
특히 스트리밍 및 다운로드 과정에서 일부 Firebase Storage의 실제 접근 주소가 그대로 노출되고 있었으며, 해당 주소만 알고 있다면 외부에서도 직접 접근 가능한 상황이 존재하였습니다.
초기에는:
- 서버 프록시를 통해 파일을 우회 전달하는 방식
- 저장소 주소 자체를 완전히 숨기는 구조
등도 함께 검토하였습니다.
하지만 실제 테스트 과정에서, Lambda 환경 특성상 대용량 파일 전달 시:
- 메모리 사용량 증가
- 응답 지연
- 스트리밍 안정성 저하
등의 문제가 발생하였고, 운영 비용 증가 가능성 또한 존재하였습니다.
결국 해당 프로젝트에서는 "주소를 완전히 숨기는 것"보다는:
제한된 시간 동안만 접근 가능한 임시 접근 권한을 발급하는 방향이
현재 운영 환경에서는 더 현실적인 선택이라고 판단하였습니다.
기존 구조의 문제점
기존 구조의 가장 큰 문제는, 실제 저장소의 접근 주소가 프론트엔드에 그대로 전달된다는 점이었습니다.
물론 Firebase Storage 자체에도 보안 규칙은 존재하지만, 한 번 노출된 URL은 외부 커뮤니티나 브라우저 캐시 등을 통해 예상보다 빠르게 확산될 가능성이 존재합니다.
특히 이벤트성 콘텐츠나 다운로드 자산의 경우:
- 비인가 공유
- 직접 링크 접근
- 트래픽 우회
- 예상치 못한 저장소 비용 증가
등의 문제로 이어질 수 있었습니다.
또한 운영 관점에서는:
- 특정 사용자가 어떤 파일에 접근하였는가
- 접근이 어느 시점까지 유효한가
- 이후 권한을 어떻게 회수할 것인가
와 같은 통제 지점이 거의 존재하지 않았습니다.
결국 단순히 "파일을 제공하는 구조"가 아니라, 접근 자체를 제어 가능한 구조로 변경할 필요가 있었습니다.
채택 이유
Signed URL 방식을 채택한 가장 큰 이유는, 바로 접근 자체에 제약을 둘 수 있기 때문입니다.
기존처럼 고정된 URL을 직접 노출하는 방식이 아니라, 서버에서 제한 시간이 포함된 임시 URL을 생성하여 전달하도록 구조를 변경하였습니다.
이를 통해:
- 일정 시간이 지나면 자동 만료
- 외부 공유 링크의 지속 사용 제한
- 저장소 직접 접근 최소화
- 다운로드 흐름에 대한 서버 제어 가능
등의 효과를 얻을 수 있었습니다.
또한 해당 방식은 프록시 기반 파일 전달보다 서버 부하가 훨씬 적었으며, Lambda 환경에서도 비교적 안정적으로 운영 가능하다는 장점이 존재하였습니다.
특히 해당 프로젝트는 전국 단위 매장에서 실제 사용되는 구조였기 때문에, 이론적인 완전 차단 구조보다는:
- 운영 비용
- 응답 속도
- 유지보수 난이도
- 실제 사용 환경에서의 안정성
을 함께 고려한 방향이 더욱 중요하다고 판단하였습니다.
구조 변경 과정
최종적으로는:
- 사용자가 다운로드 요청
- Flask 서버에서 권한 검증
- Firebase Storage Signed URL 생성
- 제한 시간 포함 URL 반환
- 사용자는 제한 시간 내에만 접근 가능
형태로 흐름을 변경하였습니다.
이 과정에서 중요한 것은 단순히 URL 생성 기능 자체가 아니라, "접근 권한의 수명을 짧게 가져가는 것"이었습니다.
실제 운영에서는:
- 지나치게 긴 만료 시간은 사실상 공개 링크와 유사해지고
- 너무 짧으면 사용자 경험이 불안정해질 수 있기 때문입니다.
따라서 서비스 특성과 실제 사용 흐름을 고려하여, 현실적으로 안정적인 만료 시간을 조정하는 과정도 함께 진행하였습니다.
[1]보안은 단순히 강한 구조를 사용하는 것보다, 실제 운영 환경에서 유지 가능한 구조인가가 더 중요하다고 생각합니다.
해당 프로젝트에서는 "완전 차단"보다는:
- 제한된 접근
- 짧은 권한 유지 시간
- 서버 기반 접근 제어
를 통해 현실적인 운영 안정성을 확보하는 방향을 우선시하였습니다.
각주
보안은 단순히 강한 구조를 사용하는 것보다, 실제 운영 환경에서 유지 가능한 구조인가가 더 중요하다고 생각합니다.
해당 프로젝트에서는 "완전 차단"보다는:
- 제한된 접근
- 짧은 권한 유지 시간
- 서버 기반 접근 제어
를 통해 현실적인 운영 안정성을 확보하는 방향을 우선시하였습니다.